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ABSTRACT 



A technique for automatic, transparent, distributed, scalable 
and robust caching, prefetching, and replication in a com- 
puter network that request messages for a particular docu- 
ment follow paths from the clients to a home server thai 
form a routing graph. Client request messages are routed up 
the graph towards the home server as would normally occur 
in the absence of caching. However, cache servers are 
located along the route, and may intercept requests if they 
can be serviced. In order to be able to service requests in this 
manner without departing from standard network protocols, 
the cache server needs to be able to insert a packet filter into 
the router associated with it,, and needs also to proxy for the 
home server from the perspective of the client. Cache 
servers may cooperate to service client requests by caching 
and discarding documents based on its local load, the toad 
on its neighboring caches, attached communication path 
load, and on document popularity. The cache servers can 
also implement security schemes and other document trans- 
formation features. 

75 Claims, 10 Drawing Sheets 
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METHOD AND SYSTEM FOR DISTRIBUTED 
CACHING, PREFETCHING AND 
REPLICATION 

BACKGROUND 

Computer networks, such as the Internet, private 
intranets, extranets, and virtual private networks, are 
increasingly being used for a variety of endeavors including 
the storage and retrieval of information, communication, 
electronic commerce, entertainment, and other applications. 
In these networks certain computers, known as servers, are 
used to store and supply information. One type of server, 
known as a host or home server, provides access to infor- 
mation such as data or programs stored in various computer 
file formats but generic ally referred to herein as a "docu- 
ment". While in the Internet the documents are typically 
primarily composed of text and graphics, each such docu- 
ment can actually be a highly formatted computer file 
containing data structures that are a repository for a variety 
of information including text, tables, graphic images, 
sounds, motion pictures, animations, computer program 
code, and/or many other types of digitized information. 

Other computers in the network, known as clients, allow 
a user to access a document by requesting that a copy be sent 
by the home server over the network to the client JlnLorc!er7* 
fora-clienUto-oblain-informalion-from a~home-serverreach^ 
document typ ically h as a n^Jl^Iress J"> y_^' tijch_it_ca f 1 _b e 



20 




Transfer Prot6c^(1jTi^ 

rmnyeYicT^ as- a~U n i form ~ Reso urc e- boca tor, 

( U R b)rt hat-specifies-( a)jinTddre~i<Fo VTl^JipmjLsejyerJ'rom 
\vh ich"lo;*p|^i^inrj^^i nlorriTat ib rT irTThtT farm of a na me or a 
fn u mer icaT adcfe&s-, alicn(b)2^IocaLM ~st r ing 

r inii^Jj£ii^*i;p q uested by the elientf which 

(jTiayJie^aJiJ^^ 

Alter the user specifics a URL to the client computer, the 
address portion of the URL is sent over the network to a 
naming service such as the Domain Name Service (DNS) in 
order to obtain instructions for how to establish a connection 
with the correct home server. Once the connection with the 
server is established, the client can then retrieve the desired 
document by passing the local information text string over 
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particular, large multimedia files such as for video enter- 
tainment would still potentially displace higher priority 
types of data, such as corporate E-mails. Unfortunately, 
bandwidth allocation schemes are difficult to implement, 
short of modifying existing network communication proto- 
cols. The communication technology used on the Internet, 
called TCP/IP, is a simple, elegant protocol that allows 
people running many different types of computers such as 
Apple Macintoshes, IBM-compatible PCs, and UNIX work- 
stations to share data. While there are ambitious proposals to 
extend the TCP/IP protocol so that the address can include 
information about packet content, these proposals are tech- 
nologically complex and would require coordination 
between operators of many thousands of computer net- 
works. To expect that modifications will be made to existing 
TCP/IP protocols is thus perhaps unrealistic. 

An approach taken by some has been to recognize that the 
rapidly growing use of the Internet will continue to outstrip 
server capacity as well as the bandwidth capacity of the 
communication media. These schemes begin with the 
premise that the basic client-server model (where clients 
connect directly to home servers) is wasteful of resources, 
especially for information which needs to be distributed 
widely from a single home server to many clients. There are 
indeed, many examples of where Internet servers have 
simply failed because of their inability to cope with the 
unexpected demand placed upon them. 

To alleviate the demand on home servers, large central 
document caches may be used. Caches are an attempt to 
reduce the waste of repeated requests for the same document 
from many clients to a particular home server. By intercept- 
ing parallel requests, a cache can be used to serve copies of 
the same document to multiple client locations. 

From the client's point of view, the interaction with a 
cache typically occurs in a manner which is transparent to 
the user, but which is slightly different from a network 
messaging standpoint. The difference is that when the 
address portion of the request is submitted to the Domain 
Name Service (DNS) to look up the information needed to 
connect to the home server, the DNS has been programmed 
to return the address of a cache instead of the actual original 
home server. 

Alternatively, a server node, acting as a proxy for the 



the network directly to the home .servejjhe-servernhen-^ client, mav issue probe messages lo search for a cache copy. 
rctncves4hc-dGC4imem-fo^ 0ncc a cache copy is ibund a| a parlicu i ar llode in the 

.^andjrajisrnils the docu^nLqvxrahe-networ^iodhercncnj, nclwnrkj the request is then forwarded to that node. For 



Thj^nejwo rk_con neel i on _be L\veen-the~home-server-and~lhe— 
clien t~is~t hen-term in aledr- ~^ 

t-Computer a ndlrei work industry analysts and experts are 
presently quite concerned that traffic on the Internet is 
becoming so heavy that the very nature of the way in which 
it is possible to use the Internet may change. In particular, 
many individuals now believe that the Internet is intolerably 
slow and is no longer a reliable entity for the exchange of 
information in a timely fashion. 

Hie present bottlenecks are no doubt the result of expo- 
nential increases in the number of users as well as in the 
number of complex documents such as multimedia files 



example, under the auspices of the National Science 
Foundation, document caches have been placed at various 
locations in the United Slates in order to eliminate bottle- 
necks at cross-oceanic network connections. Generally, cer- 
tain of these caches located on the West Coast handle 
requests for documents from the Asia -Pacific and South 
American countries, and a number of those located on the 
East Coast handle requests for documents from Europe. 
Other of these national caches handle requests for popular 
documents located throughout the United States. 

However, such caching techniques do not necessarily or 
even typically achieve optimum distribution of document 



being sent. It might appear that the answer is simply to add 60 request loading. In particular, in order tor the caches to be 



more bandwidth to the physical connections between servers 
and clients. This will come, however, only at the expense of 
installing high bandwidth interconnection hardware, such as 
coaxial or fiber optic cable and associated modems and the 
like, into homes and neighborhoods around the world. 

Furthermore, added bandwidth by itself perhaps would 
not guarantee that performance would improve. In 
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most effective, the DNS name service or other message 
routing mechanism must be appropriately modified to inter- 
cept requests for documents for which the expected popu- 
larity is high. The introduction of cache copies thus 
increases the communication overhead of name resolution, 
because of the need to locate the transient copies. The name 
service must register these copies as they come into 
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existence, disseminate this information to distribute demand 
for the documents, and ensure the timely removal of records 
for deleted cache copies. Often limes, the cache lookup 
order is fixed, and/or changes in document distribution must 
be implemented by human intervention. 5 

Unfortunately, frequent and pronounced changes in 
request patterns can force the identity, location, and even the 
number, of cache copies to be highly transient. The resulting 
need for updating of cache directories means that they 
cannot typically be replicated efficiently on a large scale, 10 
which can thus turn the name service itself into a bottleneck. 

Another possible approach to implementing caches is to 
change the client/server interaction protocol so that clients 
proaclively identify suitable cache copies using a fully 
distributed protocol, for example, by issuing probes in 13 
randomized directions. Aside from the complexity of modi- 
fying existing protocols and message cost introduced by 
such an approach, such a scheme also adds one or more 
round trip delays to the total document service latency 
perceived by the client. 20 

SUMMARY OF THE INVENTION 

'itie present invention is an automatic, distributed, and 
transparent caching scheme that exploits the fact that the 
paths that document requests follow through a computer 25 
network from a client to a particular document on a par- 
ticular home server naturally form a routing graph, or tree. 

According to the invention, cache servers arc placed 
throughout the network, such that if a document request can 
be fulfilled at some intermediate node along the routing 
graph, it will be serviced by the intermediate node returning 
the cached document to the client. The document request 
messages are thus responded to before they ever reach the 
home server. Since document request messages are permit- 
ted to be routed from clients in the direction of the home 
server up the routing graph in the same manner as would 
occur in the absence of caching, naming services do not need 
modification. 

In order to be able to service requests in this manner 4n 
without departing from standard network protocols, a cache 
server includes a packet filter in its associated router. The 
lilter extracts document request packets that are highly likely 
to hit in the associated cache. 

The cache server also preferably acts as a communication 45 
protocol proxy for the home server. That is, as part of 
fulfilling document request messages at the intermediate 
node locations, the client is sent appropriate messages, 
depending upon the communication protocol in use, to spoof 
the client into believing that the document was actually 50 
received from the home server. 

The invention also provides a manner in which caching 
servers may cooperate to service client requests. In 
particular, each server has the ability to cache and discard 
documents based on its local load, the load on its neighbor- 55 
ing caches, adjacent communication path load, and on 
document popularity. For example, each server maintains an 
estimate of the load at its neighbors, and communicates its 
own load estimate to neighboring cache servers. If a cache 
server notices that it is overloaded with respect to any of its 60 
neighbors, it offloads or transfers a fraction of its work to its 
under loaded neighbors. To do so, a cache server also 
preferably learns the identity of its neighboring upstream (or 
parenl)and downstream (or child) nodes on the routing graph 
that is rooted at a given home server. ^ 

There are several advantages to the basic concepts of a 
document caching system according to the invention. 
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First, the approach does not need to request an address 
lookup from a cache directory, to redirect document 
requests, or to otherwise probe other elements of the net- 
work to locate cache copies. Location of the cache copy thus 
occurs fortuitously, along the natural path that the request 
message follows anyway. The client thus docs not experi- 
ence delays or bottlenecks associated with waiting for other 
entities in the network to find appropriate cache copies. 

In addition, the system as a whole permits cache copies of 
documents to diffuse through the network as needed, which 
in turn diffuses bottlenecks at the caches and well as along 
the communication paths. 

There is also a corresponding reduction in network band- 
width consumption and response time, because cache copies 
are always placed nearer to the original server than to the 
client, Document request messages and the documents 
themselves therefore typically do not need to travel the full 
distance between the server and each client every lime they 
are requested. Hence, overall network bandwidth is 
conserved, response times are reduced, and load is more 
globally balanced. 

The invention thus not only helps to dampen differences 
in the load demand on the host servers, but also reduces the 
load on network communication resources, without requir- 
ing any modification to existing network protocols. 

Furthermore, because cache copies arc distributed 
through the network, there is no single expected point of 
failure of the caching system, and the system is robust and 
fail-safe. 

The technique is also scalable, in the sense that as more 
cache servers are added, both clients and servers experience 
a likewise benefit. 

The invention can be used to implement additional func- 
tionality in a network. These various timet ions are a direct 
result of the fact that the packet filter implemented at the 
router associated with the cache servers can also do more 
than simply divert requests for copies of documents to the 
local cache. 

For example, popularity statistics are of necessity col- 
lected by the cache servers, in order to control the choice of 
what documents to cache. Each cache server thus keeps 
track of how many references to a particular document are 
received and from where they arc received and can deter- 
mine aggregate request amounts and request rates. This data 
can be collected at a central location, such as by network 
region, so it is then possible for a publisher of documents to 
not only obtain statistics about the hit rale on their material 
but also where in the network the hits are coming from. This 
is important not only for document popularity analysis, but 
also electronic commerce and intellectual properly tracking. 

The cache servers can also be used to host replicas of 
popular documents such as databases, search engine index 
files, and the like, by acting as load splitters from the service 
provider perspective. In other words, database providers can 
arrange to have their documents placed into the network, 
pushing out data closer to the clients that desire access lo it, 
wherever the best placements might be. 

A set of security features may also be readily attached 10 
the cache servers. 

One such feature is the authentication of the sources of 
request messages and other information. This is possible 
because the cache servers maintain information as to the 
physical source of document request messages and of the 
documcnis themselves. The mechanism also arises from the 
fact that the nodes have a filter and a packet router. The filler 
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and packet router may be used not only to keep track of how 
to redirect requests to cache copies, but also to restrict access 
to the cache copies, such as by authenticating the request for 
the information. The invention also enables various types of 
document distribution in a the network. For example, the 
invention permits document compression, which is another 
form of conserving bandwidth, or encryption, as long as a 
partial lar server and client node are committed to commu- 
nicating by using cache servers, e.g., the first and last nodes 
along the path between the client and the server in the 
network contain cache servers. 

The invention also permits the efficient caching of 
dynamic content documents. Such dynamic content docu- 
ments are of the type where what is to be returned to the 
client changes on the fly, typically in accordance with 
program instructions. When the invention recognizes the 
existence of dynamic content documents in its cache, it 
caches not only the data for the document, but also allows 
for fetching and executing of programs that specify how the 
document is to be displayed or when the data is retrieved. 

The invention also improves the delivery of stored con- 
tinuous media such as audio and video data files since the 
number of network nodes between a server and a client are 
reduced. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the advantages 
provided by the invention, reference should be had to the 
following detailed description together with the accompa- 
nying drawings, in which: 

FIG. 1 depicts a typical computer network showing a 
request path for a single document and the location of cache 
servers along the path according to the invention; 

FIG. 2 is a communication layer diagram illustrating how 
a resource manager, protocol proxy, and snooper are used to 
implement the invention; 

FIG. 3 shows the typical stages in a document request 
over the network; 

FIG. 4 is a flow chart of the operations performed by a leaf 
server located on the routing path according to the invention; 

FIG. 5 is a How chart of the operations performed by a 
intermediate non-leaf cache server; 

FIG. 6 is a (low chart of the operations performed by a last 
cache server on the routing path; 

FIG. 7 illustrates the interception of a document request 
message by an intermediate server; 

FIG. S also illustrates the interception of a document 
request message in more detail; 

FIGS. 9(a) and 9(b) illustrate how d illusion can proceed 
in a worst case client request scenario; and 

FIG. 10 illustrates how the cache servers may implement 
document transformation functions. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

1. Introduction 

Turning attention now to FIG. 1, a computer network 10 
such as the Internet, extranet' private intranet, virtual private 
network, local area network, or any other type of computer 
network consists of a number of network entities including 
client computers 12-1, 12-2, 12-3, 12-4 (collectively, clients 

12); roulers 14-1, 14-2 14-10, cache servers 164, 16-3, 

16-4, 16-6, 16-8, and 16-10, and home server 20. The 
network may make use of any and various types of physical 
layer signal transmission media such as public and private 



telephone wires, microwave links, cellular and wireless, 
satellite links, and other types of data transmission. 

Tn ifie~ll lustra led- network,' certain " miners T4~have~asso- *S 
ciajed with thecn_cache s£rve£sj^6,_whcreas other route rs.do/4 
) not Jhaye^associafed clche-servels. The cache servers idV 
include vari61is~typcs-o^storagc~fdfdocurncnts in the form I 
of a cache storage 18-1 which may include disk storage) 
' 18-1-1 and/or memory storage 18-1-2. 

'Hie clients 12 and home server 20 operate as in the prior 
in art to permit distribution of a wide variet y of information, 
typjcjuM yjjxjhe^ e n ts". sfuch documents may \ 

actually contain text, grapfficsTpi^tures^ a^AS^^^fc^'m^ 
Tputer programs and any number of lypeTBt^fOrrtfalio'n'tKal*^! 
canvbe^stored-in-a-computer^[iIe-or^paris_oLa_computCL.tile^ 
15 Furthermore, certain documents may be produced at the 
time that access is requested to them, by executing a 
program. 

It will be assumed in the following discussion that the 
network 10 is the Internet, that the information is encoded in 
20 the form of the Hyper Text Transfer Protocol (ll'ITP) 
documents, and that document request messages arc sent in 
the form of Uniform Resource Locators (URLs) using the 
TCP/IP layered protocol. This is with the understanding that 
other types of wired, switched, and wireless networks, and 
25 other types of protocols such as FTP, Gopher, SMTP, NNTP, 
etc. may make advantageous use of the invention. In 
addition, although the invention is discussed in the context 
of a client-server type of communication model, it should be 
understood that the principals of the invention are equally 
30 applicable to peer-lo-peer networks. 

A request message for a particular document, for example, 
originates at one of the client computers, such as client 12-1 . 
ThenTte^sagerisraTrequesLbyihe-cl ie nt J2 TorJ he, home se rver 
20:to^s«N^a : cop^ 
35 r hj^mg^e^^ \ 
xc^v^C^^^€'\s'^i^Q^ through one or moTc^'romb^f^," \ 
suclLas rou te rs-l^~l~l^-2^r4-3^:j n~thc- d i rcct ion of the' 

illustrated arrows, o njlsjyya y to the home server 20 . i 

In networks such as the Internet, document request mes- 
40 sages may pass through as many as fifteen or more nodes or 
"hops'" through routers 14 before reaching their intended 
destination. Requests for the same document from other 
clients, such as clients 12-2, 12-3, or 12-4 also pass through 
different routers 14 on their way to the home server 20 at the 
45 same time. 

sh^d-also-beninderst^ 



a oc^i^^p^ervers 16a re^shovynras^separal^ielements^nJ^IGr 
^jfflhafi^iiej ^ fun cti onalit y may be combined into a single] 
\ element. ' ' ~~ ~" 1 

50' A"*mociel is useful for understanding the nature of how 
requests from multiple clients for one particular document 
travel across a path the computer network 10. The model is 
that structure, T, which is induced by the elfect of routing 
algorithm on the document request messages as they travel 

55 through the network to the home server 20. As shown in 
FIG. 1, the home server 20 can thus be thought of as being 
at the root node of the structure, T, with document requests 
originating at the leaf node levels farthest away from the 
root, namely at clients 12-1, 12-2, . . . , 12-4. The structure 

60 T also includes many intermediate nodes which are located 
the routers 14. 

While the structure T of the set of paths that client 
requests follow towards a given home server 20 is accurately 
and generally described as a data directed, acyclic graph, the 

65 present exposition does not benefit from the added com- 
plexity. In particular, when a single particular document is 
considered as being located at only one home server, the 
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structure can he referred lo as a Iree wilh a single rool. Wilh 
that understanding we use the term tree to descrihe the 
structure Therein, with the understanding thai a graph model 
may also he used. Wilh this model in mind, the entire 
Internet can be thought of as a forest of trees or graphs, each 
rooted at a different home server 20 which is responsible for 
providing an authoritative permanent copy of some set of 
documents.— — ■ — - _^^ -r— — . 1 



1 nil ccq rd an ce_w.i t Lub e. i n ve a Lio a v co p ie s of rd ocu m e n is -a re" 
V J ^tecat e^ih^ie-iictworirat cachti^?veYs^i6^A^M^ 



^j'nv^ioji.Jih^^ 
\_diffusion of load, is const rai ned lu!no^[es^nr%1^ s su^t u re^ 
(rff^av^artrfe^n lo6kup the locations o£ J 

^caVhe»eopies, either~by_direci4y^£nucting the home server-, 
20>_PJL1 naming_service_ such as a Domain Name Service; 15 
( D NS)7^t5y~p75iyi ng~t he iiet worlfTif ie'afeh oPapfopriate.' 



cache- co pies.. 



J 




The present invention also assumes that cache servers 16 
lie on the path along the tree that document request messages 
would naturally take from the client 12 to the home server 
20, with the cache servers 16 cooperating to off-load excess 
load at the home server 20, or to diffuse other potential 
performance bottlenecks such as communication links Ihem- 
,/selves . In effect, the routers 14 having associated cache 
sj3rv^j^l6^iiispeQt^d ^niienr request nlessag e ]TaTke~ts-ns 
jheyjlyjby^and.inlercept any request for which it i may"b"e 
jxis^ible to fulfill by proviSlrig" a cached document instead. 

In a most gcncral^Ie^cTiplton^of-the^opcraUon 'of "the 
invention, document request messages travel up the tree T, 
from a client at which it originated, such as client 12-3, 
towards the home server 20. Certain routers encountered by 
the document request message along the way, such as router 
14-7, do not have local cache servers 16, and thus simply 
pass the document request message up 'to Findeathe next 
router in the tree, such as router 14-6. 

lowcver, certain other routers, such as router 14-6, do 
have a local cache server 16-6, in which case the document 
request message is examined lo determine if it is seeking a 
^document located in the local cache store 18. If a cache copy 
is encountered at cache server 16-6, then that copy is 
returned to the client 12, and the request message is not 
permitted lo continue on its way to the home server 20. If 
however, a cache copy is nol encountered at the particular 
cache server 16-6, the request message continues to the next 
router 14-4 on the path to the home server 20. 45 

prouter first passes -the re ou est message* lo • a \ tiro iStai&OTSi t s 

irTthjQciureC^ 

i server 16, The filter code depends o n thej ypes.olL-packels^o 
the'cac1ie~coWnt:s7thirIoad at the local cache server 16, or 
the load on the attached communication links. The filter 
causes the interception of the packet (for an attempted- 
service by the local cache server 16) or passes the packet 
hack lo the router 14 lo determine the nexi hop the packet 55 
should take on its way to the home server 20. 

Ideally, the implementation of the cache servers 16 is such 
that no changes are required to the normal operating mode 
of either clients 12 or servers 20. Another goal is to have a 
design that can be gradually deployed into the existing 60 
infrastructure of the network 10. This also requires thai any 
new mechanisms preferably be compatible with existing 
communication protocols. 
( 7 To accomplish this a cache server 16 and associated router 
J 14 preferably consist of four functional building blocks, as 
(shown in the layer diagram of FIG. 2. At a relatively higher 
layer protocol level, such as the application layer, the cache 



server 16 includes an HTTP proxy 22 and a resource 
manager 24. At a lower layer, such as the physical layer, ihe 
router typically implements a packet filler 26 and an IP 
proxy or snooper 28. 

The HTTP proxy 22 implements a standard ITITP pro- 
tocol with responsibilities including storage management 
and the maintenance of the index structures necessary for 
accessing cached documents. If the HTTP proxy 22 receives 
a request for a document nol located in the local cache 18, 
it requests ihe document from the home server 20 unci 
respond lo the request when the document arrives. The 
IT1TP proxy 22 is configured to cache documents only as 
instructed by ihe resource manager 24. . 

While FIG. 2 shows two types of proxying, namely at ihe 
HTfP and IP level, it should be understood that the imple- 
mentation can also include proxying at other layers, includ- 
ing the application layer, IP layer, or some other layer in 
between, such as a transport, session, presentation, or other 
layer. • 

The resource manager 24 implements a protocol to diffuse^ 
document copies through the network 10, as will be / 
described in greater detail below. The resource manager 24 y 
is responsible for maintaining slate information used by the 
document load diffusion mechanism. The^resoiirce manager 
,212XJ?-'.--r-'Trnintii'"' rl ^-^-^ply nr'nap*; llr; load" on ihe 
cache servers 16 themselves, bill may also be progra mmed 
to man age the era 111c on the communication paths userf^ 
intcTctmnect the routers 14. > ' ~~J~~ 

To accomplish this lo ad,managcmcnt, or to ad bala ncing, 
_the resou rce, manauer maintains inform a Um ^ahTv uXjje 
identity and the JomjjM jj^ neiuhbon m ^cac tie servers 30. The 
de-rai1s"~of 



"now neighboring cache server information 
maintained is discussed below in Section 3. 

In addition, for each document in the cache 18, the * J 
resource manager 24 distinguishes between requests L 
received through each of its neighboring cache servers 30. T 
This is done by maintaining a separate hit count for requests ) 
received from each neighboring cache server 30. Using such 
information, the resource manager 24 computes the fraction 
of excess load to be diffused. Once these fractions are 



0 ^iv>vj; 

determined, the resource manager 24 informs its under- {Ca&J!/<- 



loaded neighbors 30 whichjjggujne^ 

fraction_ of requests they should un dertake. These fractions^/' ^ °* 



arc also used to generate new filter code to be injected into 
the associated router 14. A similar process is performed by 
the under-loaded neighbors 30. If necessary, the resource 
manager 24 nt the under-loaded neighbor 20 informs the 
attached HTFP proxy 22 to add new documents lo its caehe^/ 

Other responsibilities ol the resource manager 24 include 1 
neighborhood discovery, propagating load information lo L 
the neighboring servers 30, and discovering and recovering 1 
from potential barriers to load balancing. I*hese mechanisms J 
are discussed in more detail below. 
55 The roulers 14 take an active role in assisting cache 
servers 16 lo achieve cache server and/or com mimical ion 
path balancing goals. This is accomplished by allowing the ^ 
resource manager 24 to inject functionality into the router 14 J 
in ihe form of the code thai implements the filter 26 and j 
60 snooper 28. In particular, all pa eke is passing through a j 
router 14 noT~aTlclresseTI"ciirectly to a host serve r 20 ar e lirs! 
j.iassed to tlte~sh"ooper 28. The snmperjgjrjsp ec ls_ a_ p a eke I 
a nd-dele rmjrjes flsTjvjjgj desTina lion .„a i3d„lh e_docu me n t 
re^uestecirDepending on the state of the cache server 16 and 
65 packet type, the snooper 28 could intercept the packet or 
simply forward the packet to the next hop, or router 14, 
along the intended destination path to the home server 20. 
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determine if a requested document is located at the between the client 12 and the local transport layer in the 

• local cache server 16, the snooper 28 queries the filter 26. If cache server 16, and noting the initial sequence numbers 

Nthe filter 26 indicates that the requested document is cached used by both the client 12 and the local transport layer, 

/and can be serviced locally, then the packet is intercepted After the connection is established the snooper 28"^\ 

/ and passed to the resource manager 24. Otherwise, the 5 inspects all packets that fly-by, and waits for the correspond- / 

C packet is passed on to the next hop towards the destination ing {GET} request. Once the {GET} request arrives the / 

home server 20. snooper 28 queries the local filler 26 and the resource/ 

'ITie snooper 28 is typically aware of the TCP protocol and manager 24 to determine if the requested document isr 

the structure of both TCP and HTTP packets. Another cached. If the document is cached the snooper 28 forwards! 

functionality of the snooper 28 is to extract copies of 1T1TP in the HTTP {GET} message to the local resource manager 24,1 

request packets and pass them up to the resource manager waits for the resource manager 24 to service the request, and 

24. This feature is used to assist the resource manager 24 in then terminates the connection. Otherwise, the requested 

discovering its neighborhood and recovering from potential document is not cached (i.e., the filter 26 or resource 

barriers. manager 24 missed). Several different approaches may be 

2. Handling an HTTP Document Request in a TCP/IP 15 taken to servicing the document request at this poini^V 

Network Current implementations of networks 10 that use In a first approach, the TCP connection is handed off, 

H1TP rely on the layered TCP/IP protocol for reliable wherein the snooper 28 closes the server hall" of the spooled 

end-to-end communication between clients 12 and servers TCP connection with the client 12, and forwards the docu- 

20. This layering divides the normal processing of a request men! request in the form of a composite "piggy back" 

message into three steps; connection establishment (i.e., 20 {SYN+GET} message in the direction of the home server 

TCP-lcvcl three way handshake in the form of {SYN} 20. In addition, the {SYN+GET} message contains all the 

messages), H1TP document request/reply in the form of state information needed to hand -off the server half of the 

{GET} messages, and connection termination in the form of TCP connection to any other intermediate cache server on 

{FIN} messages. the path to the home server 20 which happens to cache the 

This process is depicted in FIG. 3, where the client 12 first 25 requested document, 

issues a {SYN} message with a sequence number to the In a second alternative approach, the snooper may act as 

home server 20, and the home server 20 returns a {SYN} a TCP relay, maintaining the TCP connection with the client, 

message with an acknowledgment {ACK}. In response to and relaying the {SYN+GET} message on a separate con- 

this, the client 12 then sends a document request in the form ncction to the next intermediate cache server on the path to 

of a {GET} message that includes the URL of the desired 30 the home server 20. 

document. The document is then forwarded by the home The above hand-off process is illustrated in the llow chart 

server 20 to the client 12. After the client 12 returns an of FIG. 4. This process is carried out by a particular class of 

acknowledgment, the server 20 and client 12 terminate the cache servers 16 referred to as leaf node servers 38, which 

connection by exchanging {FIN} and {ACK} messages. are the cache servers .16 that are on the extreme lower level 

The main hurdle in actually implementing the cache 35 nodes of the tree T, i.e., the first servers to intercept a {SYN} 

servers 16 as explained above in such an environment is the packet from a client 12. The leaf node servers 28 in the tree 

requirement that they need to identify the document T depicted in FIG. 1 are cache servers 16-1, 16-6, and 16-8. 

requested by a client 12; However, as seen in FIG. 3 the URL As shown in step 41 of FIG. 4, when a leaf node server 

information is typically advertised by an IT1TP client 12 38 receives a {SYN} packet, the home server 20 is proxied 

only after a TCP/IP connection has already been established 40 for, or "spoofed", by establishing a TCP connection directly 

with the home server 20. One possible solution would thus between the leaf node server 38 and the client 12. The leaf 

be to have all such connections be established with the home node server 38 then waits to intercept the corresponding 

server 20 and have snoopers 28~at intermediate routers 14 {GET} request from the client 12. 

intercept all {GET} packets. Even though this approach Note that spoofing thus occurs in the sense that packets 

might relieve a significant amount of load from a home 45 exchanged between the client 12 and a cache server 16 are 

server, it still required that TCP connections associated with modified by the snooper 28 in the above scenario. In 

such documents reach the home server 20, which defeats the particular, the network address of a cache server 16 which is 

purpose of attempting to off-load the home server 20. During servicing a request is replaced with the network address of 

high demand periods, such requests would amount to a Hood the home server 20 and in a connection hand-off, the 

of {SYN} requests on the home server 20, In addition, if the 50 sequence numbers of bytes issued by the cache server 16 

initial {SYN} is not intercepted, both establishing and tear have to follow the sequence number as determined by the 

down of connections becomes significantly more compli- leaf server 38. 

cated. Returning to step 41, if the requested document passes the 

To overcome this hurdle, in the preferred embodiment, cache query test by the filter 28, and in step 42, and if the 

intermediate routers 14 have some awareness of the TCP 55 resource manager 22 detects that the document is present in 

protocol. TCP aware routers 14 are able to detect TCP the local cache and will permit access to it, then the 

connection requests to all IT1TP servers (i.e., a {SYN} document request is serviced locally, in step 45. In step 45, 

packet directed to the HTTP port), and have the ability to act the {GET} command is forwarded to the resource manager, 

as a proxy for, or "spoof* the home server 20. which then replies with the requested document. Finally, the 

' 1 "h is functionality is implemented by the snooper 28. In 60 TCP connection between the leaf server 38 and the client 12 

particular, snoopers 28 located in routers 14 on the path to is closed, by spoofing the home server 20 once again and 

a home server 20 inspect packets that tly-by, identify such issuing the closing {FIN} and {ACK} messages to the 

packets, and intercept any {SYN} packets directed to HTTP client. 

home servers 20. As {SYN} packets do not contain any Otherwise, if there is a miss in step 42 or 43, the snooper 

information identifying which document the client 12 65 28 forwards a {SYN+GET} packet in the direction of the 

intends to request, the snooper 28 acts as a proxy for, or home server 20, and then closes the server half of the 

"spoofs'" the home server 20, by establishing a connection spoofed TCP connection, so that another cache server on the 
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tree may service il if possible. The steps (J) and e) in FIG. 4 
may be asynchronous events and may typically occur in 
parallel. The snooper 28 at a leaf server 38 then has to 
acknowledge the reception of the {GET} request. 

In the scenario depicted in FIG. 1, the upstream interme- 
diate non-leaf nodes 39 include those with cache servers 
16-3, 16-4, and 16-10. The cache servers 16 located at the 
no n- leaf nodes 39 need lo process. {SYN+ GET) packets in 
a slightly different manner. In particular, the snooper 28 in 
a non-leaf node 39 intercepts {SYN+GET} packets only if 
the requested document is cached and the local cache server 
16 has sufficient capacity to service it. 

FIG. 5 is a detailed flow chart of this process as performed 
at the non-leaf intermediate nodes 39. As shown in step 51, 
to service such a request, the snooper 28 first spoofs upon 
receipt of the {SYN} from the leaf node 38, and intercepts 
the following {GET} request. In the following steps 52 and 
53, queries are made to the filter 26 and resource manager 
24 as before, to determine if the {GET} can be processed 
locally. 

If the request can be processed locally, step 55 completes 
the proxying for the home server 20 by establishing the 
server half of the TCP connection with the client 12, issuing 
the {GET} lo the resource manager 24, returning the docu- 
ment to the client 12, and closing the TCP connection. 

If the {GET} message cannot be processed locally, step 
54 is executed, where the {SYN+GET} is forwarded to the 
next node in the tree T 

The main advantage of processing {SYN+GET} packets 
differently in the intermediate non-leaf nodes 39 is that a 
TCP connection is only handed-oll once lo ihe particular 
intermediate node 39 lhal actually has the requested docu- 
ment. Another advantage is that the {SYN+GET} contains 
all the state information needed for connection hand-off (i.e., 
no additional state information is exchanged between the 
snooper 28 at the leaf node server 38 and that at the 
intermediate node 39 which is actually caching the requested 
document.) 

One drawback of piggy-backing {SYN+GET} packets in 
this manner is lhal home servers 20 will not interpret such 
packets properly without adapting their transport protocol to 
deal with such packets. To avoid this problem and ensure 
interoperability with current network protocols, an addi- 
tional precaution can be taken by requiring that the snooper 
28 located ai the last intermediate node 39 before a home 
server 20 intercept all {SYN+GET} packets. Thus, when 
none of the leaf node servers 38 or in termed iale node servers 
39 cache the requested document, the last intermediate 
server 39 intercepts the {SYN+GET} and relays an explicit 
HTTP {GET} request to the home server 20. 

To accommodate this case, step 54 of FIG. 5 can be 
replaced with the processes illustrated in FIG. 6. In this case, 
in step 61, where the next upstream node along the path, T, 
(or parent node) is not the home server 20, then step 62 is 
entered, where the {SYN+GET} is forwarded to the next 
intermediate node on T. 

However, if the next node is a home server 20, then the 
step 63 is performed. In particular, snooper 28 establishes 
the server half of the TCP connection with the client 12, and 
replaces the {SYN+GET} with a {PROXY_GET} request 
to the local resource manager 24. The resource manager 24 
translates Ihe {PROXY__GET} request to an explicit {GET} 
issued to the home server 20. The response of the home 
server 20 response is then relayed to the client 12 in the same 
manner as if the cache server was caching the requested 
document. 

Another shortcoming of the caching technique described 
thus far is thai ihe path along the tree T between a particular 



client 12 and the home server 20 can change after a leaf node 
server 38 or an intermediate node server 39 decides to 
service a request. This may occur, for example, when a 
network connection, or link, is lost between two server 

5 nodes. FIG. 7 shows this relatively rare case where the path 
between the client 12 and ihe home server 20 changes while 
an intermediate cache server l6/> is processing a document 
request from client 12. All { ACK}s sent by the client 12 will 
now follow the new path, through a new cache server 16,v, 

in to the home server 20. This causes cache server 16/; to 
time-out and retransmit its packets. 

To solve this problem, the snooper 28 at server 16b may 
keep track of the number of times a packet is re -transmitted. 
If a packet is re-transmitted more than a predetermined 

35 number of times, for example, three times, the snooper 28 
then assumes that the path between the client 12 and the 
home server 20 has changed, and then lakes steps to termi- 
nate the connection with the client 12. In particular, the 
snooper 28 aborts the connection with the client 12 and 

20 aborts the connection with cache server 16/?, simultaneously 
spoofing the home server 20 and sending a reset packet (i.e., 
an {RST} packet) lo the client 12. 

In another approach Ihe leaf node servers 28 closest to the 
clients 12 and the last hop nodes closest to the server 20 are 

25 provided with only one possible route to the clients 12 and 
servers 20, respectively. This is accomplished by having the 
cache servers forward client request messages over cache 
scrver-to-cachc server permanent TCP connections, instead 
of simply letting the request messages follow their normal 

30 routes. The set of connections, being implemented as a set 
of properly joined TCP connections, thus automatically 
adapts to any changes in IP routing as the network configu- 
ration changes. 
3. Neighborhood Discovery 

35 However, any^resultimpchanges in the configuration of 
adjacent cache servers* must, also be detected ^by communi- 
cation with neighboring cache servers jn order to 'achieve 
resource load balancing and other advantages possible with 
(the invention. In particular, each cache server 16"parlicipal- 

io/im 
Uti 

routing tree T, a cache server 16 has to distinguish between 
upstream servers (located at parent nodes) and down stream 
servers (located at child nodes). A par titular node, i, in the 

45 tree T is the parent of a node j, if i is the first cache server 
16 on the route from j to the home server 20, in which case 
node j is also referred to as the child of node i. 

One method for a cache server 16 to discover its neigh- 
borhood requires some assistance from the underlying router 

50 L4 and snooper 28. At selected times, the resource manager 
24 asks the local router 14 to issue neighborhood discover 
messages to each destination in a routing table which the 
router 14 maintains. 

These neighborhood discovery" packets are then' inter- 

55 cepled by a given snooper at another node having a cache 
server L6 in the tree. Il is then responsibility of the inter- 
cepting cache server 16 to send a reply to the resource 
manager 24 at the cache server 16 that issued the neighbor- 
hood discover packet, announcing that il is a parent (e.g., 

60 that it is closer to the home server 20 than the issuing cache 
server) and the identity of ihe Iree T that il- is on. The 
destination port for neighborhood discover packets may be 
assigned an unlikely port number, to ensure that the desti- 
nation home server 20 does not attempt lo process 

65 un-intercepted neighborhood packets. A hop count field can 
also be used lo limil neighborhood discover packets from 
excessive forwarding. 



^-'ing in the above-described scheme has to determine which 
nther servers are in its neighborhood. In addition, on each 
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The main drawback of ihis approach is lhat it would flood 
the network with neighborhood discover packets. An alter- 
native approach is to use document request message packets 
(i.e., the {SYN+GET} packets) lhat fly-by the filter in each 
cache server 16 anyway. 
Q In this approach, each document request message contains 
\ a field identifying the previous hop, thai becomes, under the 
L scenario implemented above, an identification of the last 
/ cache server 16 lhat a particular request packet passed 
I through. 

As a request passes through a router 12 (i.e., it is not 
intercepted), the local snooper 28 stamps the IP address of 
the attached cache server 16. When a cache server 16 wants 
to discover its neighborhood, it then instructs its attached 
snooper 28 to extract the last observed destination and last 
hop address from request packets and then passes this 
information up to the local resource manager 24. « 

As shown in FIG. 8, a typical HTTP {GET} message 
follows a path from the client 12 through A to the home 
server 20 and is intercepted by intermediate cache, 16c. 
While cache server 16c is processing the request, the path 
between the home server 20 and the client 12 changes 
causing all acknowledgments to use a different path/ 

Using this information the resource manager 24 at cache 
server 16c determines both which routing trees it is on and 
any down stream cache servers 16 on each tree. 'Once server 
16c determines that server 16/? is its downstream child oh 
tree T, cache server 16c has to explicitly inform cache server 
16/; that it is its parent on T. To reduce the number of 
messages exchanged between the different components 
(snoopers 28 and resource managers 24), the snoopers 28 
can cache a number of packets and forward ihem all at once 
to the resource managers' 24. 

Neighborhood information is maintained for a predeter- 
mined number, .such as two, of neighborhood discovery 
epochs. If no requests are received through a child cache 
server 16/? during these periods, the child cache server 16/; 
is removed from the cache server 16c*s model of the 
neighborhood. The" parent cache server 16c Ihen also 
informs I he child cache server 166 of its intention to do so. 

It is also possible that a cache server 16 does not have a 
parent snooper 28 on the routing tree to the home server 20. 
In this case, the snooper 28 at cache server 16/? sends a 
neighborhood discovery packet in the direction of the home 
server 20. An upstream snooper such as the one at server 16c 
receives the packet and informs 16/? that it is its parent on the 
tree to the home server 20. However, if the snooper 28 at 16b 
does not have a 'parent node such as 16c on Ihe tree to home 
server 20 it replaces 16/? address on the neighborhood 
discovery packel and forwards it in the direction of the home 
server 20. 

Ill is neighborhood discovery scheme has a number of 
advantages. First, the routing tree T does not have to be 
completely constructed for the caching protocol to. start 
operating. Another advantage is that the cooperating cache 
servers 16 can dynamically discover and adaptlo ^routing 
changes. "Finally the protocol is totally distributed and is 
therefore robust against server failures. 
4. Load Balancing 
f" Unlike most other caching/schemes, the'eaching scheme 
^according to the invention requires distribution of cache 
fcopies to the cache servers 16 prior to 'clients actually 
Requesting them. In other words, documents are moved 
among the cache servers 16 in anticipation of future docu- 
ment requests, rather than in direct response to any one 
particular document request message by the clients 12. 

The above scheme of document caching and neighbor- 
hood discovery lends itself to a number of different types of 



such cache load distribution and/or load balancing objec- 
tives for both the cache servers 16 as well as the commu- 
nication paths which interconnect them. In the preferred 
embodiment, this load distribution scheme attempts to avoid 

5 introducing an overhead that grows quickly with the size of 
the caching system, by using a dilTusion based caching 
algorithm that relies strictly on local information. 

In particular, the resource managers 24 create cache 
copies only when an upstream ("parent"') node in the routing 

in tree T detects a less loaded downstream ("child") node or 
link, to which it can shift some of its document service load 
by giving it a copy of one of its cached documents. "Load" 
herein can be a number of different performance criteria 
such as rate of request fulfillment, alien (response time, or 

15 fraction of time the server is busy. \P / ^rO\Aj^^ r 

An imbalance in the opposite direction causes a child 1 
node to delete some of its cached documents, or to otherwise ( 
reduce the fraction of requests for these documents that it j 
wishes to serve. 

20 f*" Typically, documents which are the one being requested 
Vof parent nodes most often by "a- child node according to 
/ some measure are the^oqnr£nts_which are directed to less 
/loaded child nodes. 

Similarly, when a cache server T6 must choose- to drop 

25 documents from its local cache store 18, such documents are 
those typically being the least requested documents. 

More particularly, when relegating load to a neighbor, a 
cache server 16 can push or release a document to a child or 
a parent, respectively. There arc two goals with the present 

30 document caching by diffusion mechanism, which typically 
do not exist in traditional load diffusion processes. This is 
manifested in the need for the cache servers to determine 
which document to replicate, as well as to determine what 
fraction of document requests (i.e., load) should be relegated 

35 to an underloaded neighbor 30. 

A first goal is to determine how a cache server selects a 
document to pass to an underloaded neighbor. An objective 
here is lo extract the maximum capacity of all of the cache 
servers 16 in the n e t work ._ A s^^ mdjjbject ivc,is^tp^£ed u ce 

40 respons e, time, h v jii qy i n & „ po nu 1 a r—docu m e n Is close r to 
clientaand less popular documents away from-cIientsTalTby 
c re a t i ngHhT*" le a st ~ n u m be f ~df 7epiicYs~.~Tr)ese~ goals are 
accomplisHecl~wm'le also co7isideTihg"^communication path 
load between cache servers 16. 

45 To achieve these objectives, an overloaded cache server 
located' at node i determines the least underloaded cache 
server at a child node j such that 



50 LfiW&Ci 

where L, is the load at a particular cache server i, and Ci is 
the set of all cache servers. The overloaded cache server i 
pushes to the child j a fraction of the requests for the most 
popular document. Specifically, a document d is pushed 
x from node i to node j if it has the following properly 



/> /V ( ( 0-max^/' y; (£j) 

60 where Di is the set of documents cached at node i. In the 
other direction, a document d is released bv node i to node 



65 



This policy is called max-min document diffusion, and it 
will satisfy the first two goals stated above. 
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A given cache can be viewed as a bin thai is lo be filled 
with documents in such a manner as to contribute the most 
to alleviating load. Thus, the larger the load associated with 
a given document, the smaller the number of documents that 
need to be placed in the particular cache. Max-min docu- 
ment diffusion provides a least number of documents in a 
cache lo satisfy this third condition. 

Having now determined which documents to diffuse, a 
cache server must also figure out how to change the fraction 
of requests that they intercept when relegating their load lo 
a neighbor. This fraction can be determined by considering 
how a cache server pushes a fraction of the load imposed by 
a document. Specifically, assume that node i is the parent of 
node j and that i is overloaded with respect toj. Furthermore, 
assume that node i wishes to push a number of requests 
equal to R r -,-(d) of a total number of requests that it serves for 
document d to node j. If the total number of requests is 
defined as 



then the number of requests serviced by node i for document 



d is therefore given by 



Using the above values of A' ;V (d) and R'y,<d) it is straight- 
forward to see that 



and by algebraic manipulation, thai the new value of 



Once node j receives this informal ion it computes 



and reflects these updates in its local filter code. To complete 
the analysis, note lhat the number of requests filtered by 
node j increases by R jY (d). It is also known that 



30 



and, after pushing R,y(d) requests to node j, node i will be 
serving a number of requests given by 



where 



and A ;7 (d) represents the number of requests not intercepted 
by node j after the push to node j takes effect. Of A' /( (d) the 
new fraction intercepted by node i is denoted by (iy/d). Note 
also lhat 



50 



55 



After computing the new fraction py,(d), node i updates its 
associated filter and forwards a copy of document d to node 65 
j, directing node j to increase the number of requests that 
node j intercepts by R 0 <d). L^i.^L^t^ 



and, by substituting the new value of [3', (l/ (d) one obtains 



M*C-* ft ' 



and by algebraic manipulation, that 

ft;;(d) 



thus completing the analysis. 

With large documents, it may be advantageous for ihc 
local cache 18 to only include a portion of the requested 
document. In this event, the cache server can begin to 
provide the locally cached portion of the document lo the 
client 12, while at the same time requesting the remainder of 
the document be sent by the home server 20. 

Other criteria may include document size, document type, 
direction of transmission, or priority associated with par- 
ticular documents. 

The cache server 16 and router 12 may also make use of 
communication buffers in order lo favor message traffic 
which is determined to have higher priority. 

Related documents of the same types or which are rec- 
ognized in some way by cache servers L6 as normally being 
requested together in close succession can be shifted 
between cache servers in the same operation. 
^ Each cache server 16Js^thus-givcnMhe.abilil,y4o^iche and 
discard documents based upon its local load, its neighbors' 
<Toacls~ t comm u n ica l io n p a^lcmtTirrtd\Tn^Io^ment altribu les 
/ such as popularity, size, cost to fetch, etc. In particular, each* 
"-server maintains an estimate of the toad at its neighbors 
and/or also transmits at various times, or "gossips" about its 
actual load to neighboring cache servers 16. If a cache server- 
16 notices that it is overloaded in some respcel as compared 
to its neighbors, it relegates a fraction of its future predicted 
work lo its less loaded child or parent neighbors as described^ 
above. 

The invention thus also lends itself to load splitting, where 
neighbor ("sibling") nodes on the same path in the routing, 
tree T for a given home server may share the request load for 
a particular document. 

The above document diffusion algorithm may experience 
certain difficulties in optimized load distribution. In 
particular, a given cache server j can become a potential 
barrier to cache copies when it has at least two child cache 
servers k and k\ and a parent cache server i, such that the 
load, L, on each server satisfies the expression: 
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and cache server j does not cache any of the files required by 
its under- loaded child k. 

FIG. 9(a) illustrates an example of such a situation. The 
caching system consists of a home server 20 (at node 
number 1) and three intermediate servers 39 (as nodes 2, 3, 5 
and 4.) Requests arc only being generated by the leaf nodes, 
in particular, documents d_l and d„2 are being requested 
by node 4, and d_3 is being requested by node 3. The figure 
shows Ihe placement of cache copies at particular nodes and 
the requests serviced by each caciied copy. tn 

In this example, the cache server 16 at node 2 is the 
potential barrier. It cannot diffuse any load to the cache 
server at node 3, since it does not cache d_3. In addition, the 
cache server 16 at node 2 isolates the cache server at node 
1 from recognizing the existence of the problem. 15 

One possible optimized load assignment would distribute 
the load evenly among all four nodes with each node 
servicing requests. FIG. 9(b) illustrates file cache and load 
distributions that would satisfy this condition. 

The diffusion based scheme can be altered, however, so 20 
that a cache server 16 can detect such undesirable stales as 
shown in FIG. 9(a) and recover from them. In particular, a 
cache server k can assume that its parent server j is a 
potential barrier if k remains under-loaded, relative to j , for 
more than a predetermined number of time epochs, such as 25 
two, without action taken by j to correct the under- loaded 
situation. In the example of FIG. 9(a), cache server k would 
correspond to node 3, with cache server j corresponding to 
node 2. Upon detecting a lack of diffused load from its 
parent node k, the child node can infer that the parent node 30 
does not cache any of the documents requested by the 
subtree rooted at k. Once copies of these documents are 
eventually served to it, the server k can then cache them 
normally. This technique is referred to as tunneling, because 
server k in this case is able to obtain and cache copies even 35 
in the presence of a parent node j which represents a high 
load barrier. 
5. Other Features 

The invention can be used to implement additional func- 
tionality in a network. These various functions are a direct 40 
result of the fact that the filter 26 located at the routers 14 can 
do more than simply divert requests for copies of documents 
to the local cache server 16. 

For example, document popularity statistics arc of neces- 
sity collected by the cache servers 16 v in order to contrql the 45 
choice of which document to cache and in which cache 
server. 'Hie- cache server 16 at each node keeps track of how 
many references to particular documents are coming in from 
where and knows an aggregate request amount. 

This data can be collected at a central location, and 50 
arranged by groups of cache'' -servers 16, such as by groups 
of cache servers 16 that are located in a particular network 
region. By collecting data in this fashion, it is then possible 
for the publisher of document to not only obtain statistics 
about the "hit rate" on their material by specific clients, but 55 
also in which sub -port ion of the network 10 the hits are 
coming from. 

The invention also enables a type of accelerated distribu- 
tion of documents into-lhe network 10 in anticipation of 
demand. 60 

The cache servers 16 can also be used to host replicas of 
databases, search index files, and -other popular documents 
by acting as load splitters from the service provider per- 
spective. In other words, database providers can arrange to 
have their documents placed into the network 10, pushing 65 
out data closer to the clients 12 that desire access to it, 
wherever these placements might be. 



The cache servers may also implement authentication of 
the sources of request messages and other information. This 
can be done because the cache servers 16 automatically 
maintain information as to the client 12 which was the 
source of a particular document request message. If the 
client 12 is not among the authorized requesters for the 
document, the request message can be terminated at the 
cache server 16 before it even reaches the home server 20. 

Selective security can also be provided for as well. The 
mechanism arises from the fact that the nodes each have a 
filler 26, a resource manager 24, a cache repository 18, and 
an ITITP proxy 22. The filler 26 may be used not only to 
keep track of how to redirect requests for cache copies to the 
HTTP proxy 22, but may also restrict access to the cache 
copies, such as by authenticating the request for the infor- 
mation. As long as the first and last hop along the path from 
the client 12 to the server 20 are trusted, since the links 
between the caches servers 16 can easily be arranged to be 
trusted links, a secure link can be provided between the 
clients 12 and the home server 20 via the cache servers L6. 

More gcnerically, the cache servers 16 may transform 
documents at several points during their distribution by the 
home server 20 and subsequent delivery to clients 12. Such 
transformations may enable and/or implement several fea- 
tures that add value to caching a document or program, 
including such features as compression or encryption of 
documents and/or programs. Furthermore, any known secu- 
rity techniques can be applied as transformations at the 
source, destination or both (in the case of a transaction). In 
addition to encryption and decryption, these include 
authentication, authorization (access control), non- 
repudiation, and integrity control, lliese security techniques 
can use cryptographic techniques that usually require a key, 
and optionally use the physical path to a cache server to 
strengthen authentication, authorization, and non- 
repudiation. 

In typical applications, these transformations will be 
matched (e.g., for every encryption there should be a match- 
ing decryption) and used individually. However, they may 
also be composed at different points in the lifetime of a 
document. For example, a document may be compressed, 
encrypted, decrypted, and decompressed, all a I different 
points. 

FIG. 10 illustrates one possible approach for applying 
transformations to documents. In this example, distinct 
transformations may occur at four different times as a 
document is distributed by the home server 20 and delivered 
to the client 12: 

at lime Tl, as the request is made by the client .12 
at lime T2, as the request is forwarded to server 20 
at time T3, as the reply is sent by ihe server 20 
at time T4, as the reply is forwarded to the client 12 
Note that even though the transformations in FIG. 10 are 
associated with four phases of communication, in reality, 
transformations are performed by the nodes themselves. 
Thus, Tl may be performed on Ihe request by cache server 
16-6 after it is received, or by client 12 before it is sent. In 
the former case, cache server 16-6 is performing the trans- 
formation. In the later case, the client 12 is performing the 
transformation, and merely tunneling ihis through cache 
server 16-6. Likewise, as the request is forwarded to the 
home server 20 the transformation 17 is performed by cache 
server 16-7 or home server 20. The same alternatives apply 
for T3 and T4, as the reply is sent from home server 20 and 
ultimately forwarded to client 12. 

Where the transformations as performed in FIG. 10 have 
an important role is in key placement for security (or any 
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olher transformations which requires input olher than Ihe 
document). If the cache servers 16 themselves are imple- 
menting security, cryptographic keys must be distributed to 
the cache servers 16, as needed. In this case, end-to-end 
security can be provided by adding a secure channel 
between client 12 and cache server 16-6 as well as between 
cache server 16-7 and server home 20. If the client 12 and 
home server 20 implement their own end-to-end security the 
cache servers 16 do not hinder, and possibly cooperate in, 
distributing keys to the client 12 and home server 20. 

FIG. 10 shows the cache servers 16-6 and 16-7 at the 
edges of the network, whereby there is a direct path between 
client 12 and cache server 16-6 as well as between cache 
server 16-7 and home server 20. However, the design as 
described does not preclude a more general configuration, 
when transformations are performed by intermediate cache 
servers 16-9 and 16-10. In other words, in FIG. 10 a 
transformation may be made at an intermediate cache server 
16-9, 16-10 during the request, or reply, or both. 

The scheme also allows for a form of transparent docu- 
ment compression, which is another form of conserving 
bandwidth, as long as a particular home server 20 and client 
12 are committed to communicating by using cache servers 
16. In particular, after the first hop along the path between 
the client 12 and the server 20, the first leaf node server 16-6 
can implement compression or encryption in a manner 
which is transparent to both the client 12 and the home 
server 20. 

Documents can also be virus-scanned or code-cert ificd 
prior to being forwarded. 

The invention also permits the efficient caching of 
dynamic content documents, where the end result of which 
data is actually returned to the client changes on the fly. Such 
documents may include, for example, documents having 
embedded Java code. 

The cache servers 16 can accomplish efficient distribution 
of such dynamic content documents by caching not only the 
data for the document, but by also caching the programs that 
specify how the document is to be displayed when the data 
is retrieved. If the programs are of the type that are normally 
executed at the client 12 at the time of display of the 
documents, then the programs and the data are simply 
transferred to the client 12. 

It', however, the programs arc of the type which the client 
12 expects will be running on the home server 20, the cache 
server 16 performs an additional level of home server 
spoofing by also running the programs. In this instance, it 
may be necessary for the cache server 16 to maintain an 
interactive session state with the client 12 in order to 
complete the spoofing of the home server 20. 

The invention also inherently improves the delivery of 
stored media such as audio and video data files since number 
of hops between a home server 20 and a client 12 are 
reduced. 

While we have shown and described several embodiments 
in accordance with the present invention, it is to be under- 
stood that the invention is not limited thereto, but is sus- 
ceptible to numerous changes and modifications as known to 
a person skilled in the art and we therefore do not wish to be 
limited to the details shown and described herein but intend 
lo cover al! such changes and modifications as are obvious 
to one of ordinary skill in the art. 

What is claimed is: 

1. In a system containing a plurality of computers which 
communicate over a network using communication 
protocols, with the computers at certain nodes in the network 
acting as home servers for storing information in the form of 
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documents, and with certain other computers acting as 
clients that send document request messages to the servers 
at an application layer, the document requests message being 
requests for documents stored at the home servers, a method 
of fulfilling document request messages comprising the 
steps of: 

(a) storing local cache copies of documents al a plurality 
of intermediate node locations in the network; and 

(b) in response lo a particular one of the clients generating 
a particular application layer document request mes- 
sage addressed to a particular one of the home servers, 
attempting lo fulfill the particular application layer 
document request message at one of the intermediate 
node locations by, at a selected communication layer 
lower than the application layer, 

(i) intercepting the document request message at an 
intermediate node location through which the docu- 
ment request naturally travels, the intermediate node 
being located along a path through the network from 
the client towards the home server, the path being a 
route from the client to the home server as deter- 
mined by the home server address, and correspond- 
ing to an identical path that the message would travel 
through the network in the absence of any cache 
copies being stored at intermediate node locations; 
and 

(ii) returning one of the local cache copies to the 
application layer at the client, such that the applica- 
tion layer request message is intercepted by the 
lower layer at the intermediate node and such that the 
application layer on the server does not receive 
application layer document request message. 

2. A method as in claim I additionally comprising the step 
of, at selected intermediate nodes: 

(c) if a particular document request message cannot be 
fulfilled by providing one of the local cache copies, 
forwarding the request message towards the home 
server along the path by continuing to address the 
request message to the particular home server. 

3. A method as in claim 1 wherein the step of fulfilling the 
particular document request additionally comprises, in at 
least one intermediate node, wherein the intermediate node 
is neither a client nor a home server, the step of: 

(c) storing local cache copies of particular documents 
which are also stored on other intermediate nodes; 

(d) determining the identity of a neighboring intermediate 
node that stores local cache copies; and 

(e) allocating the fulfillment of document request mes- 
sages among the intermediate node and the neighboring 
intermediate node based upon the availability of docu- 
ment request message load fulfillment resources at the 
intermediate node. 

4. A method as in claim 3 wherein the message load 
fulfillment resources include the caches. 

5. A method as in claim 3 wherein the message load 
fulfillment resources include communication path load. 

6. A method as in claim 3 in which the step of allocating 
the fulfillment of document request messages additionally 
comprises the step of: 

(f) exchanging status messages between the intermediate 
node and the neighboring node, the status messages 
including information selected from at least one of 
processing load, communication path load, document 
size, document request message response lime, docu- 
ment request message request rate, document request 
message rate of change, or home server operability. 
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7. A method as in claim 1 wherein Ihe step of fulfilling the (c) recording load statistics as to the number of request 
particular document request additionally performs commu- messages fulfilled by providing one of the local cache 
nication path load distribution between paths that intercon- copies to the client. 

nect the nodes, by further comprising the steps of: 16. A method as in claim 1 additionally comprising the 

(c) storing local cache copies of particular documents 5 step of, at the selected intermediate nodes: 

which are also stored on other nodes; (c) recorc]ins reques t message statistics as to the number 

(d) determining the identity of a neighboring node that 0 f req uest messages received and fulfilled for a par- 
stores local cache copies; and ticil | ar document. 

(c) allocating the fulfillment of document request mcs- 17 A metnoc i as [ n c \ a [ m 1 additionally comprising the 
sages among the intermediate node and the neighboring l0 step 0 f f at lne selected intermediate nodes: 

intermediate node based upon the communication path . . .. . .u 1 r 

j oac j r r (c) recording response time statistics as to the number ot 

8. Amethod as in claim 2 additionally comprising the rcc l u . es, , messages received for documents stored at a 
steps of, at selected intermediate nodes: ' particular home server. 

(d) determining an identity of a first neighboring node „ l8 ' A melhod as di,1 , m 1 where , ,n dotl '™"' 

from which a particular document request messat-e i.s messages are received al the intermediate nodes on a plu- 

received' and ** rahty of communication paths, and the method additionally 

(e) determining an identity of a second neighboring node comprises the step of, at the selected intermediate nodes: 
to which a particular document request message is M recording request message statistics to track which 
routed on the path to the home server if the particular 2Q document request messages are received from a par- 
document request message cannot be fulfilled by " ticular path. 

returning the local cache copy to (he client. 19 A method as in claim 1 wherein document request 

9. A melhod as in claim H wherein the step of storing local messages are received al the intermediate nodes on a plu- 
cache copies further comprises the step of: ralilv of communication paths, and the method additionally 

(0 determining a node stale parameter al ihe first neigh- „ forecasts communication path usage by criteria selected 

burin* node and a node state parameter al Ihe local " from one of overa11 network demand, network regional 

node, and when the first neighboring node and local demand, or by specific client demand, 

node state parameters are different by a predetermined 20 A melhod as in claim 1 wherein the step ot hilhlhng 

amount from one another, forwarding a copy of at least document request messages addit.onally comprises the step 

one of the local cache copies to the first neighboring 10 

node for storing at the first neighboring node location. ' ( c ) authenticating a node over which a document request 

10. A method as in claim 9 wherein the node state message arrives from a client, prior to forwarding the 
parameters are selected from the group consisting of rale of document request message . 

request fulfillment, change in rate of request fulfillment, 21. A method as in claim 1 wherein the step of fulfilling 

document size, document fetch response time, communica- 35 document request messages additionally comprises the step 

tion path load, cache server load, or home server operational °f ; 

status. ( c ) authenticating a node from which the cached docu- 

11. A method as in claim 8 wherein the step of storing ment originated prior to returning the local cache copy 
local cache copies further comprises the step of: to the client. 

(f) determining a node state parameter at the second 40 22. A method as in claim 1 wherein the home servers also 
neighboring node and a node state parameter at a local store programs for operating on the documents, and step (b) 
node, and when the node slate parameters at the second additionally comprises the step of, at the intermediate node: 
neighboring node and local node differ by a prcdetcr- (c) storing local cache copies of selected programs as 
mined amount, deleting at leasi one of the local cache certain selected programs related to requested tlocu- 
copies. 45 ment copies are obtained from the home servers. 

12. A method as in claim 11 wherein the node stale * 23. A melhod as in claim 22 additionally comprising the 
parameters are selected from the group consisting of rate of step of: 

request fulfillment, change in rate of request fulfillment, (d) executing the local cache copies of selected programs 

document size, document fetch response time, communica- at the intermediate nodes upon demand from the client, 

lion path load, cache server load, or home server operational 50 24. A melhod as in claim 22 additionally comprising the 

status. step of: 

13. A melhod as in claim 8 wherein ihe step of storing (d) maintaining an interactive session between the inter- 
local cache copies further comprises the step of: mediate node and the client such that the intermediate 

(t) determining a node state parameter at the second node acts as the home server would act in the event ihat 

neighboring node and a node state parameter at a local 55 the home server had fulfilled the document request 

node, and when the node stale parameters al the second message. 

neighboring node and local node different by a prede- 25. (Amended) A melhod as in claim 1 wherein the step 

termined amount, in the step of fulfilling, reducing a of fulfilling the document request message additionally 

proportion of the document requests that are fulfilled by comprising the step of: 

providing local cache copies to the client. 60 (c) applying selected programs to the local cache copies 

14. A melhod as in claim 1 wherein the step of fulfilling to oblain results, prior to returning the results of apply- 
additionally comprises the step of: ing the programs to the client. 

(c) returning the local cache copy to the client if a local 26. A melhod as in claim 1 wherein the documents are 

node state parameter differs from a predetermined selected from the group of multimedia documents, 

amount. 65 programs, data bases, compressed data, or encrypted data. 

L5. A method as in claim 1 additionally comprising the 27. A method as in claim 8 wherein multiple intermediate 

step of, at the selected intermediate nodes: nodes are located between the home server and the client, 
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and wherein a particular document is pushed into the net- 
work by routing it to a plurality of nodes depending upon an 
expected rate of demand upon the document. 

28. A method as in claim 9 wherein the predetermined rale 
of request fulfillment depends upon document attributes 5 
selected from the group of expected rate of request 
fulfillment, expected change in rate of request fulfillment, 
document size, expected document fetch response lime, 
expected communication path load, or expected cache server 
load. 

29. A method as in claim 1 additionally comprising the 
step of, at the intermediate nodes, 

(c) storing, with the local cache copies, data indicating a 
condition as to the release of the local cache copies; and 

(d) returning the local cache copy to the client only when _ 
the condition is satisfied. 

30. A method as in claim 29 wherein the condition is a 
time of release of the document. 

31. A method as in claim 1 wherein the step of storing 
cache copies is selectively executed based upon predeter- 
mined conditional criteria. 20 

32. A method as in claim 31 wherein the predetermined 
conditional criteria include time of day. 

33. A method as in claim 31 wherein the predetermined 
conditional criteria is at least one selected from the group of 
document size, desired document request message response ~ ? 
time, document request message rate, rale of change of the 
document request message rate, cache server load, commu- 
nication path load, or home server operational status. 

34. A method as in claim 1 wherein the step of storing 
cache copies additionally comprises the step of storing a ^ 
partial copy of a document which is larger than a predeter- 
mined size. 

35. A method as in claim 1 additionally comprising the 
step of: 

(c) deleting cache copies of documents selectively 
executed based upon predetermined conditional crite- 
ria. 

36. A method as in claim 35 wherein the predetermined 
conditional criteria include time of day. 

37. A method as in claim 35 wherein the predetermined 
conditional criteria is at least one selected from the group of 
document size, desired document request message response 
time, document request message rate, rate of change of the 
document request message rate, cache server load, or com- 
munication path load. 

38. A method as in claim 1 additionally comprising the 
steps of, to maintain cache consistency: 

(c) at the home server, attaching a document expiration 
lime stamp to the document; ?Q 

(d) at an intermediate node, examining the time stamps 
attached to a cached document to determine if the 
document has expired; and 

(e) if the cached document has expired, either deleting or 
refreshing it. 5s 

39. A method as in claim 1 additionally comprising the 
steps of: 

(c) at the home server, attaching a document modification 
time stamp to the document; and 

(cl) at an intermediate node, estimating the modification 60 
rale of the document, and if the document modification 
rate is greater than (he request rate by a predetermined 
amount, deleting the cache copy, and if the modifica- 
tion rate is less than the request rate by a predetermined 
amount, requesting an updated cache copy. 65 

40. In a system containing a plurality of computers which 
communicate over a network using a layered communica- 
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lion protocol, with the computers at certain nodes in the 
network acting as home servers for storing information in 
the form of documents, and with certain other compuiers 
acting as clients that .send document request messages to the 
servers at an application layer level, the document request 
messages being requests for documents stored at the home 
servers, a method of fulfilling document request messages 
by transparent proxy ing comprising the steps of: 

(a) storing local cache copies of documents at a plurality 
of intermediate node locations in the network; and 

(b) in response to a particular one of the clients generating 
a particular application layer document request mes- 
sage intended to be senl to a particular one of the home 
servers, fulfilling the particular application layer docu- 
ment request message at one of the intermediate node 
locations along a path from the client to the home 
server through which the document request would 
naturally How in the absence of any cache servers, by 
intercepting the document request message and return- 
ing one of the local cache copies in a response message 
to the application layer at the client, such that the 
application layer request message is intercepted at the 
intermediate node and such that a network connection 
is not established wiih the application layer on the 
home server and such that the addresses in a response 
message are the same as if the home server had fulfilled 
the document request message. 

41 . A method as in claim 40 wherein an intermediate node 
comprises a cache server and a router, additionally compris- 
ing the steps of, at the router: 

(c) recognizing document request messages that are to in 
be intercepted, and extracting such messages for pro- 
cessing by the cache server. 

42. A method as in claim 1 additionally comprising the 
steps of: 

(c) simultaneously pre -fetch ing related documents 
together, wherein related documents are those docu- 
ments that are most frequently requested in close 
succession. 

43. A method as in claim 1 additionally comprising the 
steps of: at the client, 

(c) generating a connection request message which 
requests a communication path to be established 
between the client and a home server; and at an 
intermediate node, 

(d) upon receiving a connection request message from the 
client, waiting for the receipt of a document request 
message, and forwarding the connection request mes- 
sage and the document request message together 
addressed to the home server. 

44. A method as in claim 43 additionally comprising the 
steps of: 

at an intermediate node which caches the document 
indicated by the request message, 
(c) acknowledging the connection request to the client, 
and returning the requested document to the client. 

45. A method as in claim 1 additionally comprising the 
step of: 

(c) operating a cache server which selects documents to 
store in a local cache and documents to remove from 
the local cache, such that the cache server selects a 
most often requested document to replicate at a neigh- 
boring cache server located at a node in the path, and 
chooses the least often requested documents to drop 
from its own memory. 

46. A method as in claim 1 wherein each intermediate 
node includes a resource manager associated with it, and the 
resource manager performs the steps of: 
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(c) allocating the use of communication buffers to buffer 
incoming and outgoing messages so as to favor mes- 
sage traffic that is designated as more important. 

47. A method as in claim 46 comprising the steps of: 

(d) allocating the use of the communication buffers and 
communication path bandwidth based upon content 
attributes selected from the set of document size, docu- 
ment type, direction of transmission, or priority. 

48. A method as in claim 1 additionally comprising the 
steps of, at the intermediate nodes, 

(c) comparing a node state parameter at the intermediate 
node with a node slate parameter at a neighboring 
cache server; and 

(d) if the node slate parameters at the neighboring cache 
server and the intermediate node differ by a predeter- 
mined amount for more than a predetermined period of 
time, at the intermediate node, inferring that the neigh- 
boring cache server docs not cache one or more docu- 
ments being served by the intermediate node. 

49. A method as in claim 48 wherein the node state 
parameters are selected from the group consisting of rate of 
request fulfillment, change in rate of request fulfillment, 
document size, document fetch response time, communica- 
tion path load, home server operability, or cache server load. 

50. In a system containing a plurality of computers which 
communicate over a network, with certain computers acting 
as home servers for storing information in the form of 
documents, and with certain other computers acting as 
clients that send messages which are requests for documents 
stored at the home servers, a method of fulfilling document 
request messages by distributed caching comprising the 
steps of: 

(a) routing document request messages from a client to a 
home server along a path from the client to the home 
server, the path comprising a plurality of hops includ- 
ing a plurality of intermediate node locations in the 
network through which the document request would 
naturally How through in the network in the absence of 
cache servers; 

(b) at selected intermediate nodes, 

(i) storing local cache copies of selected documents at 
intermediate nodes; 

(ii) filtering document request messages to determine if 
a particular document request message made by a 
client can be fulfilled by providing one of the local 
cache copies to the client, and if so, returning the 
local cache copy to the client; and 

(iii) if not possible to so fulfill the document request 
message forwarding the document request message to 
the home server along the path which the document 
request message would naturally follow through the 
network. 

51. In a system containing a plurality of computers which 
communicate over a network, with the computers at certain 
nodes in the network acting as home servers for storing 
information in the form of documents, and with certain other 
computers acting as clients that send document request 
messages which are requests for documents stored at the 
home servers, a method of fulfilling documenl request 
messages at node through which the document request 
messages travel comprising the steps of: 

(a) storing local cache copies of documents at a plurality 
of intermediate node locations in the network; 

(b) in response to a particular one of the clients generating 
a particular document request message intended to be 
sent to a particular one of the home servers; 
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(i) determining a path for the particular document 
request message to travel from the particular client to 
the particular home server along a path of nodes 
located in the network between the particular client 
and the particular home server, the path being deter- 
mined by an address of the home server and the path 
comprising a plurality of the intermediate node loca- 
tions in the network; 

(ii) forwarding the request message along the path as 
determined by the home server address in the request 
message; and 

(iii) fulfilling the particular document request message 
at one of the plurality of intermediate node locations 
in the determined path of nodes by the steps of, if a 
local cache copy is available at the intermediate 
node, returning one of the local cache copies corre- 
sponding to a document specified in the particular 
document request message, and otherwise if a local 
cache copy is not available at the intermediate node, 
forwarding the request message in the direction of 
the home server along the path. 

52. A method as in claim 51 additionally comprising the 
step of: 

(c) at the intermediate node locations, coordinating the 
step of storing cache copies and splitting document 
fulfillment among the intermediate node locations to 
distribute document request load on the intermediate 
node cache servers or home server. 

53. A method as in claim 51 additionally comprising the 
step of: 

(c) at the intermediate node locations, coordinating the 
step of storing cache copies and splitting documenl 
fulfillment among the intermediate node locations to 
distribute communication path load. 

54. A method as in claim 51 wherein the step of coordi- 
nating the step of storing cache copies among the interme- 
diate node locations to reduce document load comprises the 
steps of: 

(c) at neighboring node locations, replicating documents. 

55. A method as in claim 51 wherein the step of storing 
copies of documents at intermediate node locations addi- 
tionally comprises the step of: 

(c) alternatively making such copies available or not 
available for fulfilling documenl requests based upon 
predetermined criteria. 

56. A method as in claim 55 wherein the predetermined 
criteria is time of day. 

57. A method as in claim 51 wherein the step of fulfilling 
the particular document request message at one of the 
intermediate servers additionally comprises the steps of: 

(c) if the leaf node does not store the requested document 
opening a communication connection belween the leaf 
node and the next intermediate node by sending a 
connection request message addressed to the home 
server that is intercepted by the next intermediate node 
server, the leaf node being one of the intermediate node 
locations that initially receives the documenl request 
message from the client; and 

(d) forwarding the document request and the communi- 
cation connection to another intermediate node that is 
located closer to the home server in the network than 
the leaf node. 

58. A method as in claim 51 wherein the step of fulfilling 
the particular document request message at one of the 
intermediate servers additionally comprises the steps of: 

(c) opening a communication connection between a leaf 
node and the home server, the leaf node bein« one of 
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the intermediate node locations that initially receives 
the document request message from the client; and 
(d) relaying the document request to another intermediate 
node that is located closer to the home server in the 
network than the leaf node. 5 

59. A method as in claim 51 wherein the cache servers 
additionally perform the steps of: 

(c) acting as a communication proxy for the home server 
from the perspective of the client. 

60. A method as in claim 50 wherein the step of filtering 10 
document request messages additionally controls access to 
documents, and the method additionally comprises the step 
of: 

(c) filtering document request messages based upon a l5 
Uniform Resource Locator (URL) field in the docu- 
ment request message. 

61. A method as in claim 50 wherein the step of filtering 
document request messages additionally controls access to 
documents, and the method additionally comprises the step 
of: 

(c) tillering document request messages based upon an 
authentication field in the document request message. 

62. A method as in claim 5 1 wherein the step of returning 
the cache copy of the document to the client additionally 2 $ 
comprises the step of: 

(c) virus scanning the document. 

63. A method as in claim 51 wherein the step of returning 
the cache copy of the document to the client additionally 
comprises ihe step of: 30 

(c) code certifying the document. 

64. A method as in claim 51 wherein the step of returning 
the cache copy of the document to the client additionally 
comprises the step of: 

(c) decoding the document. 35 

65. A method as in claim 51 wherein the step of returning 
the cache copy of the document to the client additionally 
comprises the step of: 

(c) controlling access to the cache copy of the document 4f) 
based upon client authentication and home server 
request. 

66. A method of fulfilling requests for information in a 
network of computers, with at least some of the computers 

in the network acting as home servers for storing ^ 
information, and at least some of the computers acting as 
clients that send request messages to the home servers, the 
method comprising the steps of: 

(a) distributing cache copies of the information through 
the network by storing copies of the information in a 50 
plurality of computers in the network that act as cache 
servers; 

(b) routing request messages from the client to the home 
server along a path consisting of a plurality of inter- 



mediate computers in the network, the path including 
computers through which the request messages travel 
in the absence of any cache servers with at least some 
of the intermediate computers also acting as cache 
servers, the request messages initiated by a particular 
one of the clients to obtain information from a particu- 
lar one of the home servers; and 

(c) transparently processing request messages as they are 
routed through the cache servers, such that request 
messages that can serviced by the cache servers instead 
of the home servers are serviced by the cache servers, 
in a manner which is transparent to the clients and the 
home servers. 

67. A method as in claim 57 additionally comprising the 
step of: 

(d) automatically moving cache copies among the cache 
servers in the network in response to predetermined 
criteria concerning the servicing of the request mes- 
sages by the cache servers. 

68. A method as in claim 1 wherein the multimedia 
documents contain digitized information selected from the 
group of text, graphics, audio, video, programs, or other 
data. 

69. A method as in claim 1 wherein the network comprises 
a wireless network. 

70. A method as in claim I wherein the intermediate nodes 
also perform the step of: 

determining if a particular communication entity has 
failed, and if so, notifying another network entity. 

71. A method as in claim 70 wherein the communication 
entity is one of a router, communication path, or commu- 
nication path. 

72. A method as in claim 70 wherein the other network 
entity is one of another intermediate node, a network 
administrator, or other networked computer system. 

73. A method as in claim 55 wherein the predetermined 
criteria is a notification by the client. 

74. A method as in claim 55 wherein the predetermined 
criteria is a notification by the home server. 

75. A method as in claim 2 additionally comprising the 
steps of, at selected intermediate nodes: 

(d) determining an identity of a first neighboring node 
from which a particular document request message is 
received; and 

(e) determining an identity of a second neighboring node 
to which a particular document request message is 
routed on the path to the home server; 

(0 il ita particular document request message cannot be 
fulfilled satisfactorily by the intermediate node because 
of failed or slow processing at the intermediate node, 
altering the path to bypass the intermediate node. 
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